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REMARKS 



Upon entry of the present amendment, claims 1 to 8 will have been amended, claims 9 to 
70 will have been newly added and claims 1 to 70 will be pending. Claims 1 to 8 have been 
amended herein to more clearly recite the invention. Claims 9 to 70 have been added to provide 
an additional scope of coverage. No new matter has been added. 

To aid in the examination of the present application, submitted concurrently is a 
Transmittal Letter to the Official Draftsmen including Replacement Drawings for Figures 1, 2, 
2A-2C, 3-38, 38A, 39-46, 46A, 47, 48, 48A, 48B and 49-63, replacing Figs. 1-63 with formal 
drawings. Li this regard. Applicants have endeavored to aid in the clarity of the Drawings and 
their enumeration. 



Attached hereto is a marked-up version of the changes made to the specification and 
claims by the current preUminary amendment. The attached page is captioned ^^Version with 
markings to show chanees made>^' 



CONCLUSION 
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Favorable consideration and passage to issue of the application at the Examiner's earliest 
convenience are earnestly solicited. 



WOODCOCK WASHBURN KURTZ 
MACKIEWICZ & NORRIS LLP 
One Liberty Place - 46* Floor 
Philadelphia, PA 19103 
(215) 568-3100 -Telephone 
(215) 568-3439 -Facsimile 



Respectfully submitted, 



Date: November 14, 2001 




Thomas E. Watson 
Registration No. 43,243 
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Version With Markings To Show Changes Made 



IN THE SPECIFICATION: 

Please enter the following amendments to the specification: 

Amend the paragraph beginning on page 1, line 5, as follows: 

-This application is related to U.S. Patent Application No. 60/118,668, entitled 
"COMMON DISTRIBUTED OBJECT PLATFORM," filed on February 3, 1999; U.S. 

Patent Application No. 09/322.455 [ ], entitled "METHOD AND SYSTEM FOR 

TRACKING SOFTWARE COMPONENTS," filed on May 28, 1999 [(Attorney Docket No. 

30581.8002.1001)]; U.S. Patent Application No. 09/322.962 [ ], entitled "METHOD 

AND SYSTEM FOR TRACKING CLIENTS," filed on May 28, 1999 [(Attorney Docket No. 

30581.8003.1001)]; U.S. Patent Application No. 09/322.643 [ ], entitled "AUDIO 

VISUAL ARCHITECTURE," filed on May 28, 1999 [(Attorney Docket No. 

30581.8004.1001)]; U.S. Patent Application No. 09/322.459 [ ], entitled 

"METHOD AND SYSTEM FOR CONTROLLING ENVIRONMENTAL CONDITIONS," 
filed on May 28, 1999 [(Attorney Docket No. 30581.8005.1001)]; U.S. Patent Application 

No. 09/322.207 [ ], entitled "METHOD AND SYSTEM FOR DISTRIBUTING ART," 

filed on May 28, 1999 [(Attorney Docket No. 30581.8006.1001)]; U.S. Patent Application 

No. 09/322.964 [ ], entitled "METHOD AND SYSTEM FOR GENERATING A 

USER INTERFACE FOR DISTRIBUTED DEVICES," filed on May 28, 1999 [(Attorney 

Docket No. 30581.8008.1001)]; and U.S. Patent Application No. 09/322.852 [ ], 

entitled "METHOD AND SYSTEM FOR MANAGING SOFTWARE COMPONENTS," filed 
on May 28, 1999[ (Attorney Docket No. 30581.8009.1001); and U.S. Patent Application No. 

09/322.457 , entitled "METHOD AND SYSTEM FOR PROPERTY 

NOTIFICATION," filed on May 28, 1999 (Attorney Docket No. 30581.8010.1001)], the 
disclosures of which are incorporated herein by reference. ~ 

Amend the paragraph beginning at line 13 of page 2, as follows: 

—Such large distributed systems need to ensure that they can function even when portions 
of the system fail or go off-line for maintenance. For example, when one object goes down 
because of a failiu-e of one computer, the objects that reference that failed object should not also 
fail. In addition, when the failed object eventually comes up, the objects that reference that failed 
object should be able to continue to access the object. This tracking of objects as they go down 
and come up can be very complex. For example, in a large distributed system, there may be no 
guarantee that messages relating to when an object comes up or goes down are received in the 
order in which they are generated or even [event] received at all. Thus, applications accessing 
the objects need to perform these complex processes to ensure that references are current. 
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Current object models, however, provide very little support for tracking objects in such complex 
systems." 

Amend the paragraph beginning at line 13 of page 15, as follows: 

-The watching of a resource is coordinated by the bus manager, but the monitoring of a 
resource is performed on a client-to-server node basis without interaction from the bus manager. 
When a client wants to watch a resource so that it knows when the resource is in the up state, the 
client node notifies the bus manager. The resource is identified using a tracking reference. If the 
resource is already up, [then] the bus manager then notifies the client node that the resource is up. 
Otherwise, the bus manager notifies the client node when the resource comes up. When the 
client node is notified that the resource is up, it may notify the bus manager to stop watching for 
the resource. The monitoring of a resource is performed on a peer-to-peer basis. That is, once a 
client node is informed that a [an] resource has entered the up state, it establishes a connection 
directly with the server node that contains the resource. Once the connection is established, the 
client node notifies the server node periodically that it is still up and running. If the server node 
does not receive this notification, it assumes that the client node is no longer up and running and 
resets its intemal state accordingly. Similarly, if the client node receives an error when sending 
its periodic notification to the server node, it assumes the server node is down and resets its 
intemal state accordingly. When the resource goes down, the server node notifies the client node 
that the resource is now down. Each node includes clients 205, a resource tracking system 206, 
and a resource manager 207. A client requests the resource tracking system to provide pointers 
to resources and to notify the client when resources come up or go down. The resource tracking 
system interacts with the resource manager to watch, monitor, and retrieve pointers to the 
resource. The resource manager also detects when resources on its node come up and go down 
and notifies [notify] the bus manager or other nodes as appropriate. The nodes may all be 
computer systems with a central processing unit, memory, and input/output devices. The 
software components and data structures of these nodes may be stored on computer-readable 
medium such as memory, CD-ROM, flexible disk, hard disk, and so on and may be transmitted 
via a data transmission medium.— 

Amend the paragraph beginning at line 1 of page 17, as follows: 

—Figure 2B is a block diagram illustrating the watching of a resource. The client node 
2B10 is a node on which a client 2B1 1 has requested to watch for a certain resource to come up. 
The client node tracks the resource with components 2B12 of the resource manager. The 
resource manager includes a watched resource table 2B13, a process/resource hst 2B14, and 
resource directory 2B15. The client and the resource manager interact as described in Figure 2 A. 
The resource manager interacts with a bus manager 2B20 to notify the bus manager when 
resources of that node go up and come down and to request that the bus manager watch for a 
resource on the client node's behalf. The bus manager includes a bus manager component 2B21 
that has a watched resource table 2B22 and a resource directory 2B23. The watched resource 
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table at the client node contains an indication of each resource that a client located at that node 
has requested to watch along with an indication of the requesting client. The resource directory 
at the client node contains the identification of each resource that is currently up at the client 
node. The resource manager uses the resource directory to re-notify the bus manager of the 
resources that are up in the event that the bus manager goes down and then comes back up or 
when another bus manager takes control of the bus. The resource manager similarly uses the 
watched resource table to re-notify the bus manager of the resources that its clients are watching. 
The process/resource list identifies each resource by the process in which it is executing. When 
a process goes down, the resource manager can use the process/resource list to notify the bus 
manager that those resources are now down. The client node sends to the bus manager an attach 
resource message whenever a resource comes up and a detach resource message whenever a 
resource goes down. The client node sends a watch resource message to the bus manager to 
notify the bus manager to start watching for a particular resource to come up. The client node 
keeps track of the resources that it is [its] watching in the watched resource table. If a client 
requests to watch a resource that another client on the same node is already watching, then the 
client node does not need to send another watch resource message to the bus manager. The client 
node sends a stop watching resource message to the bus manager whenever it wants to stop 
watching for a resource to come up. The client node may want to stop watching for a resource 
whenever all of its clients who were watching the resource request to stop watching the resource 
or whenever the resource comes up. The client node sends a find resource message to the bus 
manager when it wants to retrieve a pointer to a resource. When a client comes up, the bus 
manager sends a watched resource is up message to each client node that is watching that 
resource. The watched resource table of the bus manager contains an identifier of each resource 
that is being watched and the client node that requested a watch of that resource. The resource 
directory of the bus manager contains an identifier of and a pointer to each resource that is 
currently up. When the bus manager receives an attach resource message, it updates the resource 
directory to indicate that the resource is up. It then checks the watched resource table to 
determine whether any client nodes are watching that resource. If so, the bus manager sends a 
watched resource is up message to each such client node. When the bus manager receives a 
detach resource message, it updates its resource directory to indicate that the resource is now 
down. When the bus manager receives a node is down message, it effectively detaches all 
resources that were attached at the node that is now down and effectively stops all the watches 
from that node.~ 

Amend the paragraph beginning at line 2 of page 20, as follows: 

"Figure 3 is a block diagram illustrating data structures of the resource tracking system. 
The resource tracking system provides a directory object 301, a list of resource reference objects 
302, and, for each resource reference object, a list of client objects 303. The directory object 
provides functions for controlling the access to resources by interacting with an installable 
resource manager. The directory object maintains a resource reference object for each resource 
that a client has registered to track. Each resource reference object contains the name of the 
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resource and, if the resource is up, a unique instance identifier of the resource (e.g., a pointer to 
the resource and the time at which the resource was created). Each resource reference object also 
contains a pointer to a client list of client objects that each represent a client that has registered to 
track the corresponding resource. Whenever a client wants to reference to a resource, it supplies 
a client object to the resource tracking system. This client object includes functions that the 
resource tracking system uses to notify the client when the resource changes its state (e.g., a 
call-back routine). Since these data structures may be accessed concurrently by multiple threads 
of execution, a concurrency management technique is used when accessing these data structures. 
For example, before accessing a data structure [structures], a thread may lock the data structure 
and then unlock it after the access is complete, hi the following, the description of the functions 
that access these data structures omit these well-known concurrency management techniques.-- 

Amend Table 1 beginning at line 10 of page 21, as follows: 



Table 1 
Directory Object 



Name 


Description 


myResRefList 


A pointer to the resource reference list for this directory object. 


addNewResClient 


A function that is invoked by a client to register that it wants to track a resource. 


ResIsUp 


A function that is invoked by the resource manager to notify the resource tracking 
system that a resource is up. 


ResIsDown 


A function that is invoked by the resource manager to notify the resource tracking 
system that a resource is down. 


busStateChanged 


A function that is invoked by the resource manager to notify the resource tracking 
system that the bus has changed state (i.e., came up or gone down). 


reevaluateRefs . 


A function that is invoked by the resource manager to notify the resource tracking 
system to reset all its references [reference] to the down state. 


clearlnitialBlock 


A function that is invoked by the resource manager to notify the resource tracking 
system to start processing notifications. 


GoingAway 


A function that is invoked by a resource reference object to notify the directory object 
that a resource reference object is going away. 


MonitorRes 


A function that is implemented by the resource manager and invoked by the resource 
tracking system to notify the resource manager to start monitoring a resource to go 
down. This function may be provided as a derivation of the directory object. 


stopMonitoringRes 


A function that is implemented by the resource manager and invoked by the resource 
tracking system to notify the resource manager to stop monitoring a resource to go down. 
This function may be provided as a derivation of the directory object. 


WatchRes 


A function that is implemented by the resource manager and invoked by the 
resource tracking system to notify the resource manager to start watching for a 
resource to come up. This function may be provided as a derivation of the directory 
object. 
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stopWatchingRes 


A function that is implemented by the resource manager and invoked by the 
resource tracking system to notify the resource manager to stop watching for a 
resource to come up. This function may be provided as a derivation of the 
directory object. 


Finders 


A function that is implemented by the resource manager and invoked by the 
resource tracking system to retrieve a pointer to a resource. This function may be 
provided as a derivation of the directory object. 



Amend the paragraph beginning at line 2 of page 23, as follows: 



"A pointer used may be "smart pointer" such that when a pointer is copied it is 
automatically reference counted; [,] when the pointer is resets [to a new] it is automatically 
released. When a smart pointer goes out of scope, its destructor releases it. The myResPtr of the 
resoiirce reference object and myRefResPtr of the client object are smart pointers.-- 

Amend the paragraph begiiming at line 5 of page 26, as follows: 

"Figures 14-19 are flow diagrams illustrating the functions of the directory objects. 
Figure 14 is a flow diagram of an example implementation of the Directory: :addNewResClient 
function. This function adds a new client object for a resource to the directory. This function is 
passed the name of the resource (resName) and the client object. In step 1401, the function finds 
the resource reference object associated with the passed resource name by invoking the 
findRefRes function of the directory object. That function searches the resource reference list 
and returns a reference to a resource reference object with that name. In step 1402, if a resource 
reference object with that name is found, then the function continues that step 1407, else the 
function continues at step 1403. In steps 1403-1406, the function adds a resource reference 
object for the named resource to the resource reference list. In step 1403, the function creates a 
resource reference object. In step 1404, the function adds the resource reference object to the 
resource reference list of this directory object. In step 1405, the function adds the client object to 
the client list of the resource reference object by invoking the add function of the resource 
reference object passing the client object. In step 1406, the function signals the clients that the 
resource is up by invoking the up function of the resource reference object. If the resource is not 
actually up, the resource tracking system will enter the watch for resource state for this resource 
and notify clients that the resource is down. In step 1407, the function adds the client object to 
the client list of the resource reference object by invoking the add function of the resource 
reference object. In step 1408, the function initializes the client object by invoking the init 
function of the resource reference object passing the client object and then retums.-- 

Amend the paragraph begiiming at line 1 1 of page 35, as follows: 

-Figure 31-34 are flow diagrams illustrating the processing of the functions of the client 
object. Figure 31 is a flow diagram of an example implementation of the Client: :resIsUp 
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function. This function is invoked when the resource comes up. In step 3101, the function sets 
the interface pointer of this client object to null. In step 3102, the function retrieves a reference 
counted pointer to the resource by invoking the getRefCountedPtr function of the resource 
reference object and saves it in a smart pointer. In step 3103, if the client object has an interface 
identifier specified, then the function continues at step 3104, else the function continues at step 
3105. In step 3104. the requested interface pointer is retrieved from the subject resource. In step 
3105, the function retrieves a pointer to the interface by invoking the query interface function of 
the resource. In step 3105, the function notifies the client derivation that the resource is now up 
by invoking the resourcelsUp function provided by the client. The function then retums.-- 

Amend the paragraph beginning at line 1 of page 36, as follows: 

—Figure 33 is a flow diagram of an example implementation of the Client: :delete Yourself 
function. This function is invoked when this client object is to be deleted. In step 3301, the 
function clears the interface identifier of this chent object. In step 3302, if this client object has a 
reference to a resource reference object, then the function continues at step 3303, else the 
function continues at step 3308. In step 3303, the function notifies the resource reference object 
that this client is going away by invoking the to be goingAway function. In step 3304, if the 
invocation is successful, then the function continues at step 3305, else the function continues at 
step 3306. In step 3305, the function decrements the reference coimt for [in] the resource 
reference object and sets its pointer to null. In step 3306, the function sets the delete flag of this 
client object to true. In the step 3307, if this client object has a reference to a resource reference 
object, then the function retums, else the function continues at step 3308. In step 3308, the 
function destructs this client object and retums. - 

Amend the paragraph beginning at line 14 of page 36, as follows: 

-Figure 34 is a flow diagram of example implementation of the Client: :resourceIsUp 
function. This function is provided by a client to specify client specific processing to be 
performed when a resource comes up. In step 3401, this function sets a resource is ug [a] flag for 
the client. The client also provides an analogous function for when a resource goes down.— 

Amend the paragraph beginning at line 23 of page 36, as follows: 

— Figures 35-39 are flow diagrams of functions of a resource manager for watching a 
resource. Figure 35 is a flow diagram of an example implementation of the ResourceUp function 
of the resource manager. The resource manager invokes this function whenever a resource at that 
node is detected as being up. The resource manager may know that a resource is up because it 
controlled the creation of the resource at startup, because it dynamically created the resource 
when requested by another resource, or because another resource created that resource and 
registered the created resource with the resource manager. This function is passed a pointer to 
the resource that is now up. In step 3501, if the bus is up, then the function notifies the bus 
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manager by invoking the attach function of the bus manager passing the identification of the 
resource that is now up^ else the function returns, hi step 3502, the function updates the local 
resource directory to indicate that the passed resource is up. The function then retums.-- 

Amend the paragraph beginning at line 1 1 of page 41, as follows: 

—Figure 45 is a flow diagram of an example implementation of the Directory: :monitorRes 
function. This function is implemented by the resource manager and is invoked by a client to 
start monitoring for the passed resource to go down. Li step 4501, the function uses the passed 
resource to identify the server node (i.e., the node where the resource is located) for the resource. 
The function may use the query interface function of the resource to retrieve a pointer to an 
interface for identifying the server node. The function also updates the monitor resource table for 
the resource and client so that the client can be notified when the resource goes down and so that 
the server node can be re-notified if it goes down and comes up. In step 4502, if a connection has 
already been established with the server node as indicated by the client connection table, then the 
function continues at step 4508, else the function continues at step 4503. hi step 4503, the 
function establishes a connection with the server node by invoking the connectClient function of 
the server node passing a pointer to an interface of the client node for receiving notifications and 
passing a client context for identifying this connection. The invocation returns a server context. 
In step 4504, if an error is detected when invoking the connectClient function, then the function 
continues at step 4505, else the function continues at step 4506. In step 4505, the function 
assumes that the [is] server node is dovm and performs the associated processing and then 
returns. In step 4506, the function updates the client connection table to indicate that a 
connection has now been established with server node with the client and server context. In step 
4507, the function signals to start sending a client is alive message periodically to the server 
node. The sending of the chent is alive message may be considered to be one form of "leasing" a 
resource. In step 4508, the function invokes the monitor resource function of the server node 
passing the identification of the resource to be monitored. The function then retums.-- 

Amend the paragraph beginning at line 5 of page 46, as follows: 

—The tracking system also provides for watching the properties of a server resource by a 
client resource. A property of a resource corresponds to data related to the resource whose value 
can be set by that resource during execution of a function of the resource. That function can be 
invoked [involved] by another software component. The function may be specifically provided 
to set the value of the property (e.g., a set property function) or may set the value of the property 
as a side effect. In one embodiment, a property watching component of the resource tracking 
system allows client resources to register their interest in receiving notifications when a property 
of a server resource is set. The client resources also specify the behavior to be performed when 
the property is set. The property watching component provides a synchronous mechanism for 
notifying client resources when the property is set. This synchronous mechanism ensures that 
client resources who are registered to watch a property are notified of the setting of the property 



-33- 



# 



DOCKET NO.: MSFT-0681/183208.1 PATENT 

before any client resources are notified of a subsequent setting of the property. The property 
watching component thus provides a mechanism for synchronizing processing among multiple 
client resources.— 

Delete the paragraph beginning on line 19 of page 48, as follows: 

--[[Add ManResIsDownBlock to Figure]]- 

Amend the paragraph beginning at line 1 of page 51, as follows: 

—Figure 61 is a flow diagram of an example implementation of a register watch function 
of a client resource. This function is passed the identification of the server resource, the name of 
the property to be watched, and identification of the cHent resource. In step 6101, if the client 
resource is already watching that property, then the function continues at step 6106, else the 
function continues at step 6102. In step 6102, the function creates a imique context for the client 
resource and property. In step 6103 [6102], the function invokes the watch property function of 
the server resource passing the name of the property and the context. In step 6104, the function 
creates a property client object for that property and adds that object to the client object list of the 
resource reference object for that resource. In step 6105, the function adds an entry to the 
context/property table. In step 6106, the function adds a property reference object to the list 
associated with the property client object and then retums.— 

Amend the paragraph beginning at line 24 of page 51, as follows: 

-The event system provides a mechanism for providing event notifications when events 
are generated by resources. An event is an asynchronous signal that is distributed to all client 
resources, also referred to as listeners, who have registered to listen for an event signal. In one 
embodiment, the event system neither guarantees that a listener will receive the events in the 
order they are generated nor guarantees that each listener will receive every event for which it is 
listening. Each event has an associated event type. A listener registers to listen for events of a 
certain event type. In one embodiment, the event types may be hierarchically organized. For 
example, one event type may be a timer event. The timer events may be further classified into 
catastrophic timer events, warning tuner events, and informational timer events, which are 
sub-events. An informational timer event may further be classified into start-up timer events and 
shut-down timer events. A listener may register to listen for events at any level in the event 
hierarchy. For example, a listener may register to listen for informational timer events. That 
listener would receive an event notification as for start-up tuner events and a shut-down timer 
events. A listener will receive event notifications for leaf events of the sub-tree corresponding 
[correspond] to the event [vent] type registered. A leaf event is m [in] event that is not further 
classified into sub-events. An event type may have its hierarchy embedded in its name. For 
example, the name of start-up timer event may be "/timer event/informational time event/start-up 
timer event."— 
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Amend the paragraph beginning at line 16 of page 52, as follows: 

—Figure 63 is a block diagram illustrating components of the event system in one 
embodiment. A client 6301 registers to listen for events by sending a listen message along with 
an event type to the listener component 6303. The client receives from the listener component an 
event notify message along with event information when an event of that event type is generated. 
The client un-registers its interest in listening for events of a certain event type by sending a stop 
listening message along with the event type to the listener component. In one embodiment, each 
node has [as] a listener component through which is routed all event-related messages for all 
listeners on that node. The listener component may in tum route event-related messages to a 
listener bus manager 6305. The listener component notifies the listener bus manager to listen for 
all event types for which listeners on that node have registered. The listener component may 
send only the listener bus manager. There is one [One] listen message for each event type 
regardless of how many listeners at that node have registered for that event type. For example, if 
a listener component receives requests from six clients, the listener component sends only one 
listen message to the listener bus manager. The listener component maintains a listener table 
cache 6306 that contains a mapping from each event type for which a listen request has been 
registered and each client that has registered for that event type. When the listener component 
receives an event notification, it uses the listener table cache to notify each listener that has 
registered for that event type. In this way, the listener component reduces the event messages 
that are sent between that node and the node of the listener bus manager. When the listener 
component receives event notifications, it queues an event notifications for each of the listeners. 
The listener component uses a separate thread for providing the event notification to each 
listener. If a single thread were used to notify each listener, the event notifications could be 
delayed to some listeners as a result of a delay or problem in notifying another listener. The use 
of a separate thread for each listener ensures that the notification to one listener will not be 
delayed as a result of an event notification to another listener. The listener component may 
receive a bus state change message. If the bus goes down and then comes back up, the listener 
component can reregister with the listener bus manager to receive the events of the event types in 
its listener table cache. The listener component may also optimize its sending of listen requests 
based on the event hierarchy. For example, if a listener registers to listen for a informational 
timer, the listener component will register that request with the listener bus manager. If another 
listener registers to listen for a start-up timer, then the listener component will not need to 
register that request with the listener bus manager. Since the listener component has already 
registered to receive a higher-level event type, it is already registered to receive all lower- level 
event types.- 

Amend the paragraph beginning at line 25 of page 54, as follows: 

" There [the] are various components in the system that are responsible for the collecting, 
storage, and possible forwarding of log records. All forms of this component are modeled by the 
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HcsLogFacility class.— 

Amend the paragraph beginning at Une 2 of page 55, as follows: 

—The HcsLogFacility class is an HcsResource derivation whose [who's] purpose is to 
provide storage and forwarding at various levels in the system. There are currently two 
implementations: the Local Log Facility, and the Central Log Facility. The HcsLogFacility 
interface is:~ 

Amend the paragraph beginning at line 20 of page 55, as follows: 

—An [A] Local Log Facility (LLF) instance (only one!) exists in every node in the system. 
The purpose of this HcsLogFacility implementation is to accept all log records from various 
HCS components on that node and to buffer them in a large circular on disk until they can be 
delivered to the Central Log Facility (CLF). The intent is that a node could survive for some 
time if the CLF were to be imavailable. One of the configuration parameters passed to each 
Local HcsLogFacility instance will be the resource name of the HcsLogFacility through which 
that instance is to forward its records. The current thinking is that this will be the name of the 
CLF^ but this is not an architectural requirement. In other words^ there could be intermediate 
levels of HcsLogFacilities placed in the system. In fact, an [on] LLF could be configured to 
forward its records to another LLF. After all an [a] HcsLogFacility is a HcsLogFacility.- 

Amend the paragraph beginning at line 9 of page 56, as follows: 

-So the question is: how do HCS components log their [there] information? To provide a 
standard and safe access to the HcsLogFacilities, there is a class family provided. The family is 
based at a class called HcsLogPort. This class implements the common behavior of all types of 
LogPorts and is functional on its own.— 

Amend the paragraph beginning at line 13 of page 56, as follows: 

-Derived from the HcsLogPort are the HcsResourceLogPort and HcsLogFacilityPort 
classes. The HcsResourceLogPort provides [provide]easy support for the resource developer 
while the HcsLogFacilityPort provides direct access to HcsLogFacilities. In general, the first is 
used by Resource derivations while the second would be used by resource servers and system 
components." 

Amend the paragraph beginning at line 18 of page 59, as follows: 

— HcsResourceImp::putLogRecord implementation: keeps an [and]intemal 
HcsLogFacilityPort instance which is used to forward records through. Before a record is 
actually forwarded, HcsResourceImp checks to make sure an HcsLogFacility has been assigned 
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[assign] to its port. If this is not the case, an attempt is made to locate the local HcsLogFacility 
for that node via the HcsResrcBusIf::locateLocalResourceById method (new). In any case, the 
log record is written [to the ]via the resource instance's HcsLogFacilityPort.— 

IN THE CLAIMS: 

Please amend claims 1 to 8, as follows: 

1 . (Amended) A method in a computer system for providing property notifications for 
properties of software components in a distributed computing environment, the method 
comprising: 

registerin g, by a first software component, an interest in watching a property of a second 
software component; 

receiving a notification when the property is set; [and] 

tracking a state of the second software component ; and [so that it can be determined] 
determining when the second software component is in a down state based upon said 
tracking . 

2. (Amended) The method of claim 1 , fiirther including retrieving the state of the property 
independently of receiving [a] the notification. 

3. (Amended) The method of claim L fiirther including un-registering [an] fiie interest in 
watching the property of the second software component. 

4. (Amended) The method of claim 1^ wherein the property has associated access rights and 
wherein an interest can only be registered by [a] the first software component if the first software 
component has [with] sufficient access rights. 

5. (Amended) The method of claim L wherein a plurality of first software components have 
registered an interest in watching the property, and wherein each software component that is 
watching the property receives notification of [the] a current setting of the property before any 
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software component that is watching the property receives a [subsequent] notification of 
[another] a subsequent setting of the property. 

6. (Amended) The method of claim K wherein a pluraUtv of first software components have 
registered an interest in watching the propertv. and wherein each software component that is 
watching the property receives notifications of [the] a pluraUtv of settings of the property in the 
same temporal order in which the pluralitv of [as the] settings occurred . 

7. (Amended) A method in a computer system for providing property notifications for 
property settings in a distributed computing environment, the method comprising: 

for each of [the] a plurality of software components, registering an interest in a property; 

and 

setting the property [multiple] a pluralitv of times: 

for each setting of the property, notifying each software component of the pluralitv of 
software components that the property has been set prior to notifying any software component of 
the pluralitv of software components of [the next] anv later setting of the property. 

8. (Amended) The method of claim [1] 7^ wherein each software component of the pluralitv 
of software components receives the notifications of the settings in the same temporal order in 
which the pluralitv of [as the] settings occurred . 

Please add claims 9 to 70, as follows: 

~9. The method of claim 1, further including, after said registering, determining when the 
second component enters an up state. 

10. The method of claim 9, wherein said registering takes place prior to instantiation of the 
second component. 
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11. A computer readable medium comprising computer executable instructions for 
performing the method of claim 1. 

12. A computer readable medium comprising computer executable instructions for 
performing the method of claim 8. 

13. A modulated data signal carrying computer executable instructions for performing the 
method of claim 1. 

14. A modulated data signal carrying computer executable instructions for performing the 
method of claim 8. 

15. A computing device comprising means for performing the method of claim 1 . 

16. A computing device comprising means for performing the method of claim 8. 

17. In a system for a distributed computing environment, wherein the system includes a 
communications bus, a bus manager having at least one bus management component, at least one 
server node and at least one client node, wherein said at least one server node, said at least one 
client node and said at least one bus management component are interconnected via said 
communications bus, and wherein each of said at least one client node includes a property 
watching component and at least one client resource that may request watching, aided by the 
property watching component, of at least one property of at least one server resource of said at 
least one server node, a method for communicating between a server resource and a client 
resource when the client resource is watching a property of the server resource, comprising: 

first registering by the client resource to track a property of a server resource; 
after the server resource enters the up state, second registering by the client resource to 
watch a property of the server resource; and 
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after the property of the server resource is set, invoking by the server resource a property 
set function of the cHent resource. 

18. A method according to claim 17, wherein said first registering includes determining that 
the property of the server resource is available. 

19. A method according to claim 17, further including receiving by the client resource an 
initial value of the property after the server resource enters the up state. 

20. A method according to claim 19, wherein the client resource does not receive any 
subsequent setting of the property until the initial value of the property is received. 

21. A method according to claim 17, wherein a server node of the at least one server node is 
also a client node of the at least one client node. 

22. A method according to claim 17, wherein the communications bus includes a medium 
having shared memory. 

23. A method according to claim 17, wherein said invoking includes passing the context 
received from the client resource and passing the value of the property. 

24. A method according to claim 23, wherein the property set function of the client resource 
uses the context to identify the property and perform the behavior specified when the client 
resource specified its interests in watching the property. 

25. A method according to claim 1 7, further including invoking on behalf of the client 
resource the stop watching property function of the server resource. 
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26. A method according to claim 17, wherein said second registering includes invoking a 
watch property function of the server resource passing at least one of (1) the identification of the 
property to be watched, (2) an identification of the client resource and (3) a context of the client 
resource that uniquely identifies that property to the client resource. 

27. A method according to claim 17, further including: 

third registering by the server resource to monitor each client resource that at least one of 
first registers and second registers, so that when a client resource goes down, the method further 
includes: 

receiving by the server resource a resource is down notification on behalf of a client 
resource; and 

upon receiving such a notification, the server resource stops notifying the client resource 
when the property is set. 

28. A method according to claim 1 7, wherein a client node having a client resource caches at 
least one property value fi-om the server resource. 

29. A method according to claim 17, wherein the property watching component of a client 
resource utilizes at least one of a directory object data structure, a resource reference object data 
structure and a client object data structure. 

30. A method according to claim 29, wherein when a property of a server resource is being 
watched, a special type of cUent object is added to the list of client objects of the resource 
reference object data structure for the watched server resource. 

31. A method according to claim 30, wherein the special type of client object indicates that it 
represents the watching of a certain property and includes a property reference object for each 
time that the client resource has registered to watch that property. 
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32. A method according to claim 31, wherein each property reference object has a function 
that is invoked when the property is set to notify the cUent resource. 

33. A method according to claim 17, wherein the at least one server node includes a 
context/client table that includes an entry for each property of a server resource that is being 
watched by at least one client resource, wherein each entry includes a context and a property 
client indicator and wherein the context uniquely identifies the server resource and property from 
the perspective of the client resoiu-ce and the property client indicator refers to the corresponding 
property client object. 

34. A method according to claim 17, wherein the client resource further includes a 
synchronize property function, wherein the synchronize property function is invoked by the 
server resource when a client resource first registers to watch a certain property of that server 
resource to provide the current value of the property to the client resource. 

35. A computer readable medium comprising computer executable instructions for 
performing the method of claim 17. 

36. A modulated data signal carrying computer executable instructions for performing the 
method of claim 17. 

37. A computing device comprising means for performing the method of claim 17. 

38. In a system for a distributed computing environment, wherein the system includes a 
communications bus, a bus manager having at least one bus management component, at least one 
server node and at least one client node, wherein said at least one server node, said at least one 
client node and said at least one bus management component are interconnected via said 
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communications bus, and wherein each of said at least one client node includes at least one client 
resource for requesting watching of at least one property of at least one server resource of said at 
least one server node, a method for watching the at least one property of the server resource by 
the client resource aided by a property watching component, including: 

first registering by at least one client resource to receive a notification when a property of 
a server resource is set; 

receiving by the client resource said notification; and 

in response to receiving said notification, performing a behavior on behalf of the client 
resource. 

39. A method according to claim 38, wherein the property is set when at least one of (1) the 
server resource performs a fixnction that replaces data upon which the value of the property 
depends, (2) when another process in the system replaces data upon which the value of the 
property depends, (3) when the value of the property is replaced in response to the invocation of 
a set property software component, (4) the server resource performs a fiinction that signals an 
event upon which the value of the property depends, (5) when another process in the system 
signals an event upon which the value of the property depends and (6) when an event upon which 
the property depends is set in response to the invocation of a set property software component. 

40. A method according to claim 38, wherein said first registering includes: 
invoking a registering software component which includes passing to the registering 

software component at least one of (1) an identification of the property, (2) a reference to the 
client resource requesting to watch the property and (3) a context used to identify the watching 
relationship within the client resource. 

41 . A method according to claim 40, wherein the identification of the property includes at 
least one of a server resource identification and a property identification within the server 
resource. 
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42. A method according to claim 40, further including: 

receiving the invocation to the registering software component by the server node; and 
adding an entry into a property/client table within the server resource for the client 
resource. 

43. A method according to claim 42, further including: 

removing the entry from the property/client table upon receiving information on behalf of 
the client resource that the interest of the client resource in the property of the server resource 
ceased. 

44. A method according to claim 42, further including: 
determining whether the entry is already in the table; and 

if the entry is not already in the table, passing an indication of the client resource and 
receiving in return a handle for identifying that registration. 

45. A method according to claim 42, further including: 
retrieving the property value for that property; and 

invoking a synchronize property function of the property watching component on behalf 
of the client resources being passed the context and the retrieved property value such that all of 
the client resources registered to watch the property are notified of the setting of the property 
before any of the client resources are notified of a subsequent setting of the property. 

46. A method according to claim 38, wherein a server node of the at least one server node is 
also a client node of the at least one client node. 

47. A computer readable medium comprising computer executable instructions for 
performing the method of claim 38. 
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48. A modulated data signal carrying computer executable instructions for performing the 
method of claim 38. 

49. A computing device comprising means for performing the method of claim 38. 

50. A server resource of a server node in a system for a distributed computing environment, 
wherein the system further includes a communications bus, a bus manager having at least one bus 
management component and at least one client node, wherein said server node, said at least one 
client node and said at least one bus management component are interconnected via said 
communications bus, and wherein each of said at least one client node includes at least one client 
resource for requesting watching of at least one property of the server resource of the server 
node, the server resource comprising: 

a property/client table that includes an entry for each property of the server resource that 
is being watched by at least one client resource of the at least one client node; 

a watch property function mechanism for receiving requests from the at least one client 
resource to watch at least one property of the server resource; and 

a stop watching property function mechanism for terminating the watching of the at least 
one property of the server resource by the at least one client resource. 

51. A server resource according to claim 50, wherein the watch property function mechanism 
is passed at least one of an indication of the property of the server resource, the identification of 
the client resource and a context. 

52. A server resource according to claim 50, wherein the watch property function mechanism 
adds a client watching property object to the property/client table to indicate that the client 
resource is watching the property. 
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53. A server resource according to claim 50, wherein the watch property function mechanism 
requests that the cUent resource be monitored using a monitoring mechanism of the system. 

54. A server resource according to claim 50, wherein each entry of the property/client table 
includes an identification of the property, one of a reference to a value for the property and a 
value for the property and a client monitoring object for each client resource that has registered to 
watch that property. 

55. A server resource according to claim 54, wherein each entry further includes one of a 
reference to a queue for storing property values and a queue for storing property values in the 
order in which they are set pending notification of each of the client resources of previous 
settings of property values. 

56. A method according to claim 50, wherein a server node of the at least one server node is 
also a client node of the at least one client node. 

57. hi a system for a distributed computing environment, wherein the system includes a 
communications bus, a bus manager having at least one bus management component, at least one 
server node and at least one client node, wherein said at least one server node, said at least one 
client node and said at least one bus management component are interconnected via said 
communications bus, and wherein each of said at least one client node includes at least one client 
resource for requesting watching of at least one property of at least one server resource of said at 
least one server node, a method for registering to watch a property of the server resource by the 
client resource, comprising: 

invoking a register watch function of a client resource, wherein the register watch 
function is passed an identification of the server resource to be watched, an identification of a 
property of the server resource to be watched, and an identification of the client resource that will 
be watching the server resource; 
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determining whether the client resource is already watching the property; and 
if the client resource is not already watching the property according to said determining, 
generating a unique context for the client resource and the property. 

58. A method according to claim 57, wherein said generating includes: 

invoking a watch property function of the server resource, passing the identification of the 
property and the context to the server resource; 

generating a property client object for that property and adding the property client object 
to a client object list of a resource reference object for the server resource; and 

adding an entry to a context/property table utilized for the server resource. 

59. A method according to claim 58, fiirther including: 

if the client resource is already watching the property according to said determining, 
adding the property reference object to the list associated with the property client object. 

60. A method according to claim 57, wherein a server node of the at least one server node is 
also a client node of the at least one client node. 

61 . A computer readable medium comprising computer executable instructions for 
performing the method of claim 57. 

62. A modulated data signal carrying computer executable instructions for performing the 
method of claim 57. 

63. A computing device comprising means for performing the method of claim 57. 

64. Li a system for a distributed computing environment, wherein the system includes a 
communications bus, a bus manager having at least one bus management component, at least one 
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server node and at least one client node, wherein said at least one server node, said at least one 
client node and said at least one bus management component are interconnected via said 
communications bus, and wherein each of said at least one client node includes at least one client 
resource has registered an interest in at least one property of at least one server resource of said at 
least one server node, a method for setting a property of the server resource by the client 
resource, comprising: 

invoking a property set function by a client resource registered with an interest in a server 
resource including: 

passing the set property function a context and a property value; 

retrieving a reference to a property client object having at least one property reference 
object from a context/client table using the passed context; and 

invoking the behavior associated with each property reference object for the property 
client object. 

65. A method according to claim 64, wherein said invoking includes: 
selecting a property reference object of the property client object; and 
invoking the value set function of the property reference object to notify the client 

resource that the property has been set. 

66. A method according to claim 65, wherein said selecting and invoking begins with the 
first property reference object and performs said selecting and invoking until all of the property 
reference objects have been selected. 

67. A method according to claim 64, wherein a server node of the at least one server node is 
also a client node of the at least one client node. 

68. A computer readable medium comprising computer executable instructions for 
performing the method of claim 64. 
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69. A modulated data signal carrying computer executable instructions for performing the 
method of claim 64. 

70. A computing device comprising means for performing the method of claim 64.-- 
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